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DETAILED ACTION 
Information Disclosure Statement 

1 . The listing of references in the specification is not a proper information disclosure statement. 37 
CFR 1.98(b) requires a list of all patents, publications, or other information submitted for consideration by 
the Office, and MPEP § 609 A(1) states, "the list may not be incorporated into the specification but must 
be submitted in a separate paper." Therefore, unless the references have been cited by the examiner on 
form PTO-892, they have not been considered. Applicant has provided a proper information disclosure 
statement, but has additionally listed some references within the specification that were not on the 
information disclosure statement. 

Drawings 

2. The drawings are objected to as failing to comply with 37 CFR 1 .84(p)(5) because they do not 
include the following reference sign(s) mentioned in the description: Figure 3, item 301 . Corrected 
drawing sheets in compliance with 37 CFR 1 .121(d) are required in reply to the Office action to avoid 
abandonment of the application. Any amended replacement drawing sheet should include ail of the 
figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. 
The replacement sheet(s) should be labeled "Replacement Sheet" in the page header (as per 37 CFR 

1 .84(c)) so as not to obstruct any portion of the drawing figures. If the changes are not accepted by the 
examiner, the applicant will be notified and informed of any required corrective action in the next Office 
action. The objection to the drawings will not be held in abeyance. 

3. The drawings are objected to as failing to comply with 37 CFR 1 .84(p)(5) because they include 
the following reference character(s) not mentioned in the description: Figure 3, item 301 d. Corrected 
drawing sheets in compliance with 37 CFR 1 .121(d), or amendment to the specification to add the 
reference character(s) in the description in compliance with 37 CFR 1.121(b) are required in reply to the 
Office action to avoid abandonment of the application. Any amended replacement drawing sheet should 
include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is 
being amended. The replacement sheet(s) should be labeled "Replacement Sheet" in the page header 
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(as per 37 CFR 1 .84(c)) so as not to obstruct any portion of the drawing figures. If the changes are not 
accepted by the examiner, the applicant will be notified and informed of any required corrective action in 
the next Office action. The objection to the drawings will not be held in abeyance. 

4. The drawings are objected to because Figure 6a-6d are presented in the form of a flowchart. 
Some IF/ELSE conditions exist in the drawings that are not treated as such in a normal flowchart. See 
Figure 6B, items 607, 608 for an example. See Figure 6B, items 612, 613 for an example. A flowchart 
usually will treat an IF/ELSE condition with a diamond giving two options to pursue. See Figure 6A of - 
U.S. Patent 6,658,454, previously granted to the inventor, for an example. Corrected drawing sheets in 
compliance with 37 CFR 1 .121(d) are required in reply to the Office action to avoid abandonment of the 
application. Any amended replacement drawing sheet should include all of the figures appearing on the 
immediate prior version of the sheet, even if only one figure is being amended. The figure or figure 
number of an amended drawing should not be labeled as "amended." If a drawing figure is to be 
canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the 
remaining figures must be renumbered and appropriate changes made to the brief description of the 
several views of the drawings for consistency. Additional replacement sheets may be necessary to show 
the renumbering of the remaining figures. The replacement sheet(s) should be labeled "Replacement 
Sheet" in the page header (as per 37 CFR 1 .84(c)) so as not to obstruct any portion of the drawing 
figures. If the changes are not accepted by the examiner, the applicant will be notified and informed of 
any required corrective action in the next Office action. The objection to the drawings will not be held in 
abeyance. 

Specification 

5. The disclosure is objected to because it contains an embedded hyperlink and/or other form of 
browser-executable code. Applicant is required to delete the embedded hyperlink and/or other form of 
browser-executable code. See MPEP § 608.01. 
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Claim Rejections - 35 USC §112 

6. The following is a quotation of the second paragraph of 35 U.S.C. 1 1 2: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

7. Claims 2, 3, 5, 8, 10-11, 13-15, 29, 37, 42-46, and 53 rejected under 35 U.S.C. 112, second 
paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter 
which applicant regards as the invention. 

8. Claims 2, 3, 5, 8, 1 1 , 1 4, 1 5, 29, 42-46, 53 refer to "a period of time." A period of time is an 
indefinite limitation. It would cause one of ordinary skill in the networking art undue experimentation to 
implement the invention because of the unknown quantity of "a period of time". For purposes of compact 
prosecution, "a period of time" will be treated as occurring over any period of time. 

9. Claim 10 recites the limitation "said sender information is transmitted during a "RCPT TO" phase 
of SMTP (Simple Mail Transport Protocol) processing". The SMTP specification in RFC 821 does not 
mention use of RCPT TO in reference to sender information, but rather in reference to recipient 
information. Using RCPT TO in regards to sender information yields a command that does not exist 
according to the RFC 821 SMTP standard. This is specifically defining a term of a claim contrary to its 
ordinary meaning. One of ordinary skill in the art would be required to undertake undue experimentation 
to implement the invention because of the use of this term in an unknown context. Therefore the claim is 
indefinite. For purposes of compact prosecution, Examiner treats claim 10 as "said recipient information 
is transmitted during a "RCPT TO" phase of SMTP (Simple Mail Transport Protocol) processing". 

10. Claim 13 recites the limitation "said sender information" in line 1. There is insufficient antecedent 
basis for this limitation in the claim. For purposes of compact prosecution, Examiner treats "said sender 
information" as "said e-mail message body data." 

1 1 . Regarding claim 37, where applicant acts as his or her own lexicographer to specifically define a 
term of a claim contrary to its ordinary meaning, the written description must clearly redefine the claim 
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term and set forth the uncommon definition so as to put one reasonably skilled in the art on notice that the 
applicant intended to so redefine that claim term. Process Control Corp. v. HydReclaim Corp., 190 F.3d 
1350, 1357, 52 USPQ2d 1029, 1033 (Fed. Cir. 1999). The term "RCPT FROM" in claim 37 is unknown to 
Examiner as a SMTP command. The SMTP specification in RFC 821 does not mention a RCPT FROM 
command. The term is indefinite because the specification does not clearly redefine the term and the m 
term is unknown in the art. For purposes of compact prosecution, Examiner treats "RCPT FROM" as 
"RCPT TO" . 

Claim Rejections - 35 USC §102 

12. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for 
the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by 
another filed in the United States before the invention by the applicant for patent or (2) a patent 
granted on an application for patent by another filed in the United States before the invention by the 
applicant for patent, except that an international application filed under the treaty defined in section 
351(a) shall have the effects for purposes of this subsection of an application filed in the United States 
only if the international application designated the United States and was published under Article 21 (2) 
of such treaty in the English language. 

13. Claims 1, 16-17, 21-22, 25, 27-28, 31-34, 41, 47-48 and 50-53 rejected under 35 U.S.C. 102(e) 
as being anticipated by Srivastava et al. (U.S. Patent No. 6,374,292). 

14. Regarding claim 1, Srivastava discloses a method for processing an incoming e-mail message 
that is being received from another domain, the method comprising: receiving at a first process a request 
from a particular domain to establish a new connection for transmitting a particular e-mail message to the 
e-mail system; in response to receipt of said request from the particular domain, creating a second 
process for handling the request to establish a new connection, said second process being connected to 
a flow control filter providing filtering on a per-domain basis; comparing the request from the particular 
domain against configurable policy rules; and denying the request if any of said policy rules would be 
violated. [Srivastava discloses using a process to define a particular domain in an email server. An 
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individual domain can be configured to allow all mail to be received if the state of the domain is active 
(establish a new connection) or if the state of the domain is inactive the domain is suspended from routing 
mail (denying the request). See Srivastava, column 7, lines 36-59. Srivastava further discusses using a 
multithreaded process, with each thread handling a connection. Examiner considers this to be equivalent 
to creating a second process for handling a new connection. Srivastava further states that using a single 
multithreaded process is beneficial by maximizing performance and stability and by minimizing system 
resource usage. See Srivastava, column 5, lines 9-15.] By this rationale claim 1 is rejected. 

1 5. Regarding claim 1 6, Srivastava is applied as in claim 1 . Srivastava further discloses the first 
process comprises a mail transport agent (MTA) process. [Srivastava states that the invention includes 
an Internet mail server with an included transfer unit (MTA). The transfer unit is coupled to the message 
store. Access to the message store is through a multithreaded process. See Srivastava, column 4, lines 
25-43. See Srivastava, column 5, lines 9-15.] By this rationale claim 16 is rejected. 

16. Regarding claim 17, Srivastava is applied as in claim 1 . Srivastava further discloses the second 
process comprises a child mail transport agent (MTA) process. [Srivastava states that the invention 
includes an Internet mail server with an included transfer unit (MTA). The transfer unit is coupled to the 
message store. Access to the message store is through a multithreaded process. See Srivastava, 
column 4, lines 25-43. See Srivastava, column 5, lines 9-15. Srivastava's multithreaded process 
accomplishes the same function as a parent process and a child process. See rejection for claim 1 .] By 
this rationale claim 17 is rejected. 

17. Regarding claim 20, Srivastava is applied as in claim 1. Srivastava further discloses creating a 
multitude of new processes for handling multiple requests to establish new connections, each new 
process being connected to said flow control filter providing filtering on a per-domain basis. [Srivastava 
discusses using multiple threads in a single process, with each thread handling a new connection. See 
Srivastava, column 5, lines 9-15. See rejection for claim 1.] By this rationale claim 20 is rejected. 

18. Regarding claim 21, the limitations of this claim are substantially the same as the limitations of 
claim 1. Therefore the rationale used to reject claim 1 is also used to reject claim 21. By this rationale 
claim 21 is rejected. 
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19. Regarding claim 22, the limitations of this claim are substantially the same as the limitations of 
claims 16 and 17. Therefore the rationale used to reject claims 16 and 17 is also used to reject claim 22. 
By this rationale claim 22 is rejected. 

20. Regarding claim 25, Srivastava is applied as in claim 21 . Srivastava further discloses the set of 
rules comprises a configurable set of rules. [Srivastava discloses a postmaster configuring the transport 
unit with configuration data in a configuration table. Examiner defines this as a configurable set of rules. 
See Srivastava, column 6, lines 26-37.] By this rationale claim 25 is rejected. 

21 . Regarding claim 27, Srivastava is applied as in claim 21 . Srivastava further discloses user- 
created class definitions specifying different classes of domains. [Srivastava discloses transfer unit 
channels (user-created class definitions) that implement specific combinations of transports and protocols 
and what destination addresses (different classes of domains) should be routed through what sorts of 
channels. See Srivastava, column 6, lines 22-30.] By this rationale claim 27 is rejected. 

22. Regarding claim 28, Srivastava is applied as in claim 27. Srivastava further discloses each said 
class definition includes a domain name corresponding to a particular domain that is to be monitored for 
filtering. [Srivastava discloses the transfer unit channels include destination address (different classes of 
domains). See Srivastava, column 6, lines 22-30.] By this rationale claim 28 is rejected. 

23. Regarding claim 31, Srivastava is applied as in claim 21 . Srivastava further discloses a given 
domain is not filtered if a corresponding rule has not been created for that given domain. [Srivastava 
discloses that if the domain set of user services is a null set, the allowed set of user level services is 
defined as the set of domain services. Examiner defines this as: if no rule exists for the domain, process 
as normal and do not filter. See Srivastava, column 7, line 60 - column 8, line 13.] By this rationale 
claim 31 is rejected. 

24. Regarding claim 32, Srivastava is applied as in claim 21 . Srivastava further discloses said flow 
control filter denies a given domain's request for a new connection if any of said rules would be violated 
by granting the request. [Srivastava discloses that the requested service is not a member of the set of 
allowed user level services (violating a rule by granting the request) an error flag is thrown (denying a 
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request for a new connection). See Srivastava, column 8, lines 10-13.] By this rationale claim 32 is 
rejected. 

25. Regarding claim 33, Srivastava is applied as in claim 21 . Srivastava further discloses requests 
for transmitting e-mail messages comprise SMTP (Simple Mail Transport Protocol) commands submitted 
to the e-mail system from different domains. [Srivastava discloses an e-mail server that can support 
multiple domains. See Srivastava, column 4, lines 10-15. E-mail message can come to the transport unit 
by way of a SMTP message. See Srivastava, column 6, lines 13-19.] By this rationale claim 33 is 
rejected. 

26. Regarding claim 34, Srivastava is applied as in claim 33. Srivastava further discloses flow 
control filter processes said SMTP commands received from different domains to ascertain whether any 
of said rules would be violated. [Srivastava discloses a transfer unit receiving a message via SMTP. See 
Srivastava, column 7, lines 5-8. The SMTP header is read to see if the message address is within the 
server domain (processing said SMTP commands). If the message is within the server domain, the 
message is filtered according to domain rules. See Srivastava, column 7, line 60 - column 8, line 13.]" By 
this rationale claim 34 is rejected. 

27. . Regarding claim 41, the limitations of this claim are substantially the same as the limitations of 
claim 1 . Therefore the rationale used to reject claim 1 is also used to reject claim 41 . By this rationale 
claim 41 is rejected. 

28. Regarding claim 47, the limitations of this claim are substantially the same as the limitations of 
claim 32. Therefore the rationale used to reject claim 32 is used to reject claim 47. By this rationale 
claim 47 is rejected. 

29. Regarding claim 48, Srivastava is applied as in claim 47. Srivastava further discloses returning 
an error code indicating why the request is denied. [Srivastava discloses when a requested service is not 
allowed (request is denied) an error flag is thrown (returning an error code).] By this rationale claim 48 is 
rejected. 

30. Regarding claim 50, Srivastava is applied as in claim 41 . Srivastava further discloses portions of 
a given e-mail message include sender information, recipient information, and message body data. 
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[Srivastava discloses forwarding message headers, which include sender information and recipient 
information. See Srivastava, column 6, lines 50-55. The purpose of Srivastava's teaching is forwarding 
messages. Forwarding messages includes forwarding message body data. See Srivastava, column 4, 
lines 25-43.] By this rationale claim 50 is rejected. 

31 . Regarding claim 51, the limitations of this claim are substantially the same as the limitations of 
claim 25. Therefore the rationale used to reject claim 25 is also used to reject claim 51 . By this rationale 
claim 51 is rejected. 

32. Regarding claim 52, Srivastava is applied as in claim 41 . Srivastava further discloses policy 
rules comprise user-edited rules created for different domains. [Srivastava discloses a postmaster (user) 
configuring (editing) different channels with configuration data stored in a configuration table (rules 
created for different domains). See Srivastava, column 6, lines 22-41 .] By this rationale claim 52 is 
rejected. 

33. Regarding claim 53, Srivastava is applied as in claim 52. Srivastava further discloses each user- 
edited rule comprises a host class definition specifying a particular domain and corresponding limits to be 
applied against that domain over a given period of time. [Srivastava has defined user-edited rules for 
particular domains. See rejection for claim 52.] By this rationale claim 53 is rejected. 

Claim Rejections - 35 USC § 103 

34. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness 

rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

35. Claims 6, 12, 14, 29-30 and 46 rejected under 35 U.S.C. 103(a) as being unpatentable over 
Srivastava and Spam! (Cranor and LaMacchia, Communications of the ACM, August 1998). 

36. Regarding claim 6, Srivastava is applied as in claim 1. Srivastava fails to disclose permitting the 
requested connection; receiving sender information about the particular e-mail message from the 
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particular domain; comparing the sender information from the particular domain against said configurable 
policy rules; and blocking receipt of the incoming e-mail message if any of said policy rules would be 
violated (blocking an e-mail message based upon the sender). 

37. However, Spam! discloses filtering e-mail from known spam senders based on information in 
message headers. [See Spam!, page 78.] 

38. It would be obvious to one of ordinary skill in the networking art at the time of the invention to 
combine the teachings of Srivastava and Spam! for the purpose of filtering suspected spam messages to 
prevent a burden on ISP systems. [See Spam!, page 78. See Spam!, page 74.] Srivastava gives 
motivation for the combination by stating that the mail server is suited for applications requiring highly 
reliable, scalable, and efficient information transport. [See Srivastava, column 4, lines 20-25.] By this 
rationale claim 6 is rejected. 

39. Regarding claim 12, Srivastava is applied as in claim 1 . Srivastava fails to disclose permitting 
the requested connection; receiving e-mail message body data about the particular e-mail message from 
the particular domain; comparing the e-mail message body data from the particular domain against said 
configurable policy rules; and blocking receipt of the incoming e-mail message if any of said policy rules 
would be violated (blocking an e-mail message based on the content in the body). 

40. However, Spam! discloses identifying spam based on information within the body of an email 
message. Spam! gives this as a filtering solution to reduce the amount of spam. [See Spam!, page 78.] 

41 . The motivation for this combination is the same as the motivation in claim 6. By this rationale 
claim 12 is rejected. 

42. Regarding claim 14, Srivastava and Spam! are applied as in claim 12. Spam! further discloses 
that configurable policy rules specify a maximum aggregate volume of e-mail permitted by a given domain 
over a period of time. [Spam! discloses that filtering can be performed on outbound and inbound 
messages. Spam! further discloses that limits can be placed on the number of outbound messages a . 
subscriber can send. See Spam!, page 79. It is Examiner's position that since the limitation on number 
of messages can be applied as an outbound filter, that the limitation can also be an inbound filter on 
messages.] By this rationale claim 14 is rejected. 
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43. Regarding claim 29, Srivastava is applied as in claim 27. Srivastava fails to disclose each class 
definition includes limits that a particular domain must adhere to over a given period of time, 

44. However, Spam! discloses that limits can be placed on a domain. [Spam! discloses that filtering 
can be performed on outbound and inbound messages. Spam! further discloses that limits can be placed 
on the number of outbound messages a subscriber can send. See Spam!, page 79. It is Examiner's 
position that since the limitation on number of messages can be applied as an outbound filter, that the 
limitation can also be an inbound filter on messages.] 

45. The motivation for the aforementioned combination of teachings is the same motivation applied to 
claim 6. By this rationale claim 29 is rejected. 

46. Regarding claim 30, Srivastava and Spam! are applied as in claim 29. Spam further discloses 
that domain limits include selected ones of: maximum number of different senders, maximum number of 
different recipients, maximum number of connections, maximum number of envelopes, and maximum 
aggregate volume of mail. [Spam! discloses limits can be placed on the number of messages a 
subscriber can send. See rejection for claim 29.] By this rationale claim 30 is rejected. 

47. Regarding claim 46, the limitations of this claim are substantially the same as the limitations of 
claim 14. Therefore the rationale used to reject claim 14 is used to reject claim 46. By this rationale 
claim 46 is rejected. 

48. Claim 35 rejected under 35 U.S.C. 103(a) as being unpatentable over Srivastava and RFC 821: 
Simple Mail Transfer Protocol (Jonathan B. Postel, ftp://ftp.rfc-editor.org/in-notes/rfc821.txt ). 

49. Regarding claim 35, Srivastava is applied as in claim 34. Srivastava fails to disclose a SMTP 
"MAIL FROM" command specifying sender information for a given e-mail message. 

50. However, RFC 821 discloses the source of the message being transmitted (sender information). 
[See RFC 821, The SMTP Procedures.] 

51 . It would be obvious for one of ordinary skill in the networking art at the time of the invention to 
combine the teachings of Srivastava and RFC 821 for the purpose of relaying mail between networks. 
[See RFC 821 , Introduction.] Srivastava gives motivation for the combination of the teachings by stating 
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that a message can be relayed using SMTP. [See Srivastava, column 6, lines 9-21 .] By this rationale 
claim 35 is rejected. 

52. Claims 7, 13, 36, 39-40 rejected under 35 U.S.C. 103(a) as being unpatentable over Srivastava 
and Spam! as applied to claim 6 above, and further in view of RFC 821. 

53. Regarding claim 7, Srivastava and Spam! are applied as in claim 6. Srivastava and Spam! fail to 
disclose sender information is transmitted during a "MAIL FROM" phase of SMTP (Simple Mail Transport 
Protocol) processing. 

54. However, RFC 821 discloses the source of the message being transmitted {sender information). 
[See RFC 821 , The SMTP Procedures.] 

55. It would be obvious for one of ordinary skill in the networking art at the time of the invention to 
combine the teachings of Srivastava, Spam!, and RFC 821 for the purpose of relaying mail between 
networks. [See RFC 821 , Introduction.] Srivastava gives motivation for the combination of the teachings 
by stating that a message can be relayed using SMTP. [See Srivastava, column 6, lines 9-21.] By this 
rationale claim 7 is rejected. 

56. Regarding claim 13, Srivastava and Spam! are applied as in claim 12. Srivastava and Spam! fail 
to disclose said e-mail message body data is transmitted during a "DATA" phase of SMTP (Simple Mail 
Transport Protocol) processing. 

57. However, RFC 821 discloses the message text (message body data) is transmitted by using the 
DATA command. [See RFC 821 , The SMTP Procedures.] 

58. The motivation used to combine the aforementioned teachings is the same motivation applied .to 
claim 7. By this rationale claim 13 is rejected. 

59. Regarding claim 36, Srivastava and RFC 821 are applied as in claim 35. Srivastava fails to 
disclose permitting the requested connection; receiving sender information about the particular e-mail 
message from the particular domain; comparing the sender information from the particular domain 
against said configurable policy rules; and blocking receipt of the incoming e-mail message if any of said 
policy rules would be violated (blocking an e-mail message based upon the sender). 
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60. However, Spam! discloses filtering e-mail from known spam senders based on information in 
message headers. [See Spam!, page 78.] 

61 . It would be obvious to one of ordinary skill in the networking art at the time of the invention to 
combine the teachings of Srivastava, RFC 821 and Spam! for the purpose of filtering suspected spam 
messages to prevent a burden on ISP systems. [See Spam!, page 78. See Spam!, page 74.] Srivastava 
gives motivation for the combination by stating that the mail server is suited for applications requiring 
highly reliable, scalable, and efficient information transport. [See Srivastava, column 4, lines 20-25.] By 
this rationale claim 36 is rejected. 

62. Regarding claim 39, Srivastava and Spam! are applied as in claim 34. Srivastava and Spam! fail 
to disclose said e-mail message body data is transmitted during a "DATA" phase of SMTP (Simple Mail 
Transport Protocol) processing. 

63. However, RFC 821 discloses the message text (message body data) is transmitted by using the 
DATA command. [See RFC 821 , The SMTP Procedures.] 

64. The motivation used to combine the aforementioned teachings is the same motivation applied to 
claim 7. By this rationale claim 39 is rejected. 

65. Regarding claim 40, Srivastava, Spam! and RFC 821 are applied as in claim 39. Spam! further 
discloses identifying spam based on information within the body of an email message. Spam! gives this 
as a filtering solution to reduce the amount of spam. [See Spam!, page 78.] By this rationale claim 40 is 
rejected. 

66. Claim 26 rejected under 35 U.S.C. 103(a) as being unpatentable over Srivastava and Apache 
HTTP Server Configuration Files 

( http://web.archive.org/web/20Q10208104821/httpd.apache.org/docs/confiqurinq.html . February 8, 2001). 

67. Regarding claim 26, Srivastava is applied as in claim 21 . Srivastava fails to disclose the 
configuration file may be a text file. 

68. However, Apache HTTP Server Configuration Files discloses that a server configuration file may 
be a plain text file. [See Apache HTTP Server Configuration Files, Main Configuration Files.] 



Application/Control Number: 09/945, 1 30 Page 1 4 

Art Unit: 2145 

69. It would be obvious to one of ordinary skill in the networking art to combine the teachings of 
Srivastava and Apache HTTP Server Configuration Files for the purpose of allowing changes to be made 
to the configuration files, [See Apache HTTP Server Configuration Files, Main Configuration Files.] 
Srivastava gives motivation for the combination by stating that the postmaster configures the server for 
proper filtering. [See Srivastava, column 6 t lines 22-41 .] Srivastava further states that the transfer unit 
can utilize text files. [See Srivastava, column 6, lines 42-43.] By this rationale claim 26 is rejected. 

70. Claims 2, 42 rejected under 35 U.S.C. 103(a) as being unpatentable over Srivastava and 
Mosberger et al. (U.S. Patent 6,438,597). 

71 . Regarding claim 2, Srivastava is applied as in claim 1 . Srivastava fails to disclose said 
configurable policy rules specify a maximum number of connections permitted by a given domain over a 
period of time. 

72. However, Mosberger discloses a connection management system for a data service system that 
limits the number of connections permitted in the data service system. [See Mosberger, column 3, line 66 
- column 4, line 2.] Mosberger states that the connections can be limited by type of connection and the 
connections can be class-based {used by a given domain). [See Mosberger, column 4, lines 3-5.] 

73. It would be obvious to one of ordinary skill in the networking art to combine the teachings of . 
Srivastava and Mosberger for the purpose of operating an e-mail service with improved overload 
behavior. [See Mosberger, column 3, lines 25-32. See Mosberger, column 4, lines 5-12.] Srivastava 
gives motivation for the combination by stating that the mail server is suited for any application that 
requires highly reliable, scalable, and efficient information transport, [See Srivastava, column 4, lines 21- 
25.] By this rationale claim 2 is rejected. 

74. Regarding claim 3, the limitations of this claim are substantially the same as the limitations of 
claim 2, Therefore the rationale used to reject claim 2 is used to reject claim 3. By this rationale claim 3 
is rejected. 

75. Regarding claim 42, the limitations of this claim are substantially the same as the limitations of 
claim 2. Therefore the rationale used to reject claim 2 is used to reject claim 42. By this rationale claim 
42 is rejected. 
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76. Claims 18-19 and 23-24 rejected under 35 U.S.C. 103(a) as being unpatentable over Srivastava 
and Ahmed et al. (U.S. Patent No. 6,704,772). 

77. Regarding claim 18, Srivastava is applied as in claim 1 . Srivastava fails to disclose a second 
process is created from said first process via a forking operation. 

78. However, Ahmed discloses using forking to send multiple email messages. [See Ahmed, column 
10, lines 21-62. It is Examiner's position that creating another email message to send is equivalent to 
creating a second process from a first process.] 

79. It would be obvious to one of ordinary skill in the networking art at the time of the invention to 
combine the teachings of Srivastava and Ahmed for the purpose of reducing processing power and 
storage space. [See Ahmed, Abstract.] Srivastava gives motivation for the combination by stating that 
using multiple threads for processing maximizes performance and scalability. [See Srivastava, column 5, 
lines 9-15.] Ahmed is analogous art because it deals with email and utilizing threads. [See Ahmed, Title.] 
By this rationale claim 18 is rejected. 

80. Regarding claim 19, Srivastava and Ahmed are applied as in claim 18. Ahmed further discloses 
the ability to see the initial message regardless of the forks. [See Ahmed, Figure 5.] Seeing the initial 
message regardless of the fork implies not altering the message for the fork, which is essentially the 
same as making a copy during a forking operation. By this rationale claim 19 is rejected. 

81 . Regarding claim 23, the limitations of this claim are substantially the same as the limitations of 
claim 18. Therefore the rationale used to reject claim 18 is also used to reject claim 23. By this rationale 
claim 23 is rejected. 

82. Regarding claim 24, the limitations of this claim are substantially the same as the limitations of 
claim 19. Therefore the rationale used to reject claim 19 is also used to reject claim 24. By this rationale 
claim 24 is rejected. 

83. Claim 9 rejected under 35 U.S.C. 103(a) as being unpatentable over Srivastava and Shaw et al. 
(U.S. Patent No. 6,282,565). 

84. Regarding claim 9, Srivastava is applied as in claim 1 . Srivastava fails to disclose permitting the 
requested connection; receiving recipient information about the particular e-maii message from the 
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particular domain; comparing the recipient information from the particular domain against said 
configurable policy rules; and blocking receipt of the incoming e-mail message if any of said policy rules 
would be violated (filtering the message based upon the intended recipient of the message). 

85. However, Shaw discloses that a message may be filtered based upon the recipient of the 
message. [See Shaw, column 5, lines 5-20.] 

86. It would be obvious to one of ordinary skill in the networking art at the time of the invention to " 
combine the teachings of Srivastava and Shaw for the purpose of filtering out junk email in order not to 
waste resources. [See Shaw, column 3, lines 43-47.] Srivastava provides motivation for the combination 
by stating that the mail server is suited for any application that requires highly reliable, scalable, and 
efficient information transport. [See Srivastava, column 4, lines 21-25.] By this rationale claim 9 is 
rejected. 

87. Claim 15 rejected under 35 U.S.C. 103(a) as being unpatentable over Srivastava and Spam! as 
applied to claim 14 above, and further in view of Shaw. 

88. Regarding claim 15, Srivastava and Spam! are applied as in claim 14. Srivastava and Spam! fail 
to disclose said maximum aggregate volume is based on total byte count of e-mail received from a given 
domain over a period of time. 

89. However, Shaw discloses limiting the size of incoming email messages based on a maximum 
number of bytes. [See Shaw, column 4, lines 15-22. Shaw limits the size of a single incoming message, 
but it is Examiner's position that this could be used to filter all messages from a domain equally as well.] 

90. It would be obvious to one of ordinary skill in the networking art at the time of the invention to 
combine the teachings of Srivastava, Spam! and Shaw for the purpose of filtering out junk email in order 
not to waste resources. [See Shaw, column 3, lines 43-47.] Srivastava provides motivation for the 
combination by stating that the mail server is suited for any application that requires highly reliable, 
scalable, and efficient information transport. [See Srivastava, column 4, lines 21-25.] By this rationale 
claim 15 is rejected. 

91. Claims 11, 44 rejected under 35 U.S.C. 103(a) as being unpatentable over Srivastava and Shaw 
as applied to claim 9 above, and further in view of Sash (U.S. Pub. No. 2003/0167250). 
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92. Regarding claim 11, Srivastava and Shaw are applied as in claim 9. Srivastava and Shaw fail to 
disclose configurable policy rules specify a maximum number of different recipients permitted by a given 
domain over a period of time. 

93. However, Sash discloses placing a limit on the number of recipients of a message. [See Sash, 
page 5, paragraph 0050. Sash discloses forwarding information templates via a content provider, but this 
limitation is equally applicable to other types of forwarding. Sash also discloses monitoring the forwarding 
of information templates by tracking email addresses. See Sash, page 5, paragraph 0053.] 

94. It would be obvious to one of ordinary skill in the networking art at the time of the invention to 
combine the teachings of Srivastava, Shaw, and Sash for the purpose of detecting undesirable activity 
such as spam. [See Sash, page 5, paragraph 0053.] Shaw gives motivation for the combination by 
stating that a message can be filtered based on the recipient attribute. [See Shaw, column 5, lines 1-20.] 
By this rationale claim 11 is rejected. 

95. Regarding claim 44, the limitations of this claim are substantially the same as the limitations in 
claim 1 1 . Therefore the rationale used to reject claim 1 1 is also used to reject claim 44. By this rationale 
claim 44 is rejected. 

96. Claim 10 rejected under 35 U.S.C. 103(a) as being unpatentable over Srivastava and Spam! as 
applied to claim 9 above, and further in view of RFC 821 . 

97. Regarding claim 10, Srivastava and Spam! are applied as in claim 9. Srivastava and Spam! fail 
to disclose sender information is transmitted during a "MAIL FROM" phase of SMTP (Simple Mail 
Transport Protocol) processing. 

98. However, RFC 821 discloses the source of the message being transmitted (sender information). 
[See RFC 821 , The SMTP Procedures.] 

99. It would be obvious for one of ordinary skill in the networking art at the time of the invention to 
combine the teachings of Srivastava, Spam!, and RFC 821 for the purpose of relaying mail between - 
networks. [See RFC 821, Introduction.] Srivastava gives motivation for the combination of the teachings 
by stating that a message can be relayed using SMTP. [See Srivastava, column 6, lines 9-21 .] By this 
rationale claim 10 is rejected. 
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100. Claims 4-5 rejected under 35 U.S.C. 103(a) as being unpatentable over Srivastava and 
Rakoshitz et al. (U.S. Patent No. 6,816,903). 

101 . Regarding claim 4, Srivastava is applied as in claim 1 . Srivastava fails to disclose if none of said 
policy rules would be violated, permitting the requested connection and incrementing a counter indicating 
how many connections have been granted to the particular domain (admission control and keeping track 
of connections present). 

102. However, Rakoshitz discloses admission control for a network (if none of said policy rules would 
be violated, permitting the requested connection) and monitoring how much bandwidth is present in the 
system (incrementing a counter indicating how many connections have been granted to the particular - 
domain). [Rakoshitz disclose bandwidth control and quality of service for sessions (connections) in place 
on the system. See Rakoshitz, column 15, lines 1-30.] 

103. It would be obvious to one of ordinary skill in the networking art at the time of the invention to 
combine the teachings of Srivastava and Rakoshitz for the purpose of preventing traffic congestion. [See 
Rakoshitz, column 14, lines 50-52.] Srivastava gives motivation for the combination by stating that the 
service must be highly reliable and efficient. [See Srivastava, column 4, lines 16-25.] By this rationale 
claim 4 is rejected. 

104. Regarding claim 5, Srivastava and Rakoshitz are applied as in claim 4. Rakoshitz further 
discloses applying different admission policies at different time intervals (after passage of the period of 
time, resetting the counter). [See Rakoshitz, column 15, lines 30-37.] By this rationale claim 5 is 
rejected. 

105. Claim 8 rejected under 35 U.S.C. 103(a) as being unpatentable over Srivastava and Spam! as 
applied to claim 6 above, and further in view of Bates et al. (U.S. Patent No. 6,779,021 ). 

106. Regarding claim 8, Srivastava and Spam! are applied as in claim 6. Srivastava and Spam! fail to 
disclose said configurable policy rules specify a maximum number of different senders permitted by a 
given domain over a period of time (detecting a large number of email messages from a domain). 

107. However, Bates discloses detecting email from a specific domain and limiting the amount of email 
from said domain. [See Bates, column 9, lines 3-33.] 
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108. Bates discloses limiting the amount of email from a domain, and Srivastava and Spam! disclose 
filtering based upon the sender of the message. It would be obvious to one of ordinary skill in the 
networking art at the time of the invention to combine the teachings of Srivastava, Spam! and Bates for 
the purpose of predicting and blocking spam. [See Bates, column 3, lines 46-63.] Spam! gives 
motivation for the combination by stating that bulk mailers are able to thwart filters easily. [See Spam!, 
page 78.] By this rationale claim 8 is rejected. 

109. Regarding claim 43, the limitations of this claim are substantially the same as the limitations of 
claim 8. Therefore the rationale used to reject claim 8 is used to reject claim 43. By this rationale claim 
43 is rejected. 

110. Regarding claim 45, Srivastava is applied as in claim 41 . Srivastava fails to disclose determining 
a maximum number of e-mail envelopes, 

111. However, Bates discloses limiting the number of messages from a source address based on a 
designated number of recipients. [An e-mail envelope goes to a recipient, so a recipient can be used as a 
count for a number of e-mail envelopes. See Bates, Figure 4A.] 

112. The motivation for combining the teachings in this claim is the same as the motivation in claim 8. 
By this rationale claim 45 is rejected. 

113. Regarding claim 49, Srivastava is applied as in claim 41 . Srivastava fails to disclose denying 
transmission of a given e-mail message upon violation of policy rules, 

1 14. However, Bates discloses a filter that designates spam and prevents transmission of it to a user 
based on a set of rules. [See Bates, Figure 4A. See Bates, Figure 4B.] 

115. The motivation for combining the teachings in this claim is the same as the motivation in claim 8. 
By this rationale claim 49 is rejected. 

116. Claim 10 rejected under 35 U.S.C. 103(a) as being unpatentable over Srivastava and Shaw as 
applied to claim 9 above, and further in view of RFC 821 . 

1 1 7. Srivastava and Shaw fail to disclose recipient information is transmitted during a "RCPT TO" 
phase of SMTP (Simple Mail Transport Protocol) processing. 
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118. However, RFC 821 discloses the intended destination user of the message being transmitted 
(recipient information) during the RCPT TO command. [See RFC 821 , The SMTP Procedures.] 

119. It would be obvious for one of ordinary skill in the networking art at the time of the invention to 
combine the teachings of Srivastava, Shaw, and RFC 821 for the purpose of relaying mail between 
networks. [See RFC 821 , Introduction.] Srivastava gives motivation for the combination of the teachings 
by stating that a message can be relayed using SMTP. [See Srivastava, column 6, lines 9-21 .] By this 
rationale claim 10 is rejected. 

120. Regarding claim 37, the limitations of this claim are substantially the same as the limitations of 
claim 10. Therefore the rationale used to reject claim 10 is used to reject claim 37. By this rationale 
claim 37 is rejected. 

121 . Regarding claim 38, the limitations of this claim are substantially the same as the limitations of 
claim 10 and its claim chain, including claim 9. Therefore the rationale used to reject claim 10 is used to 
reject claim 38. By this rationale claim 38 is rejected. 
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Conclusion 



Any inquiry concerning this communication or earlier communications from the examiner should 
be directed to Jeffrey R. Swearingen whose telephone number is (571 ) 272-3921 . The examiner can 
normally be reached on M-F 8:30-5:00. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Jack 
Harvey can be reached on (571) 272-3896. The fax phone number for the organization where this 
application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the Patent Application 
Information Retrieval (PAIR) system. Status information for published applications may be obtained from 
either Private PAIR or Public PAIR. Status information for unpublished applications is available through 
Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) 
at 866-21 7-91 97 (toll-free). 
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